DOCUMENT RESUME 



ED 405 828 



IR 018 268 



AUTHOR 

TITLE 

PUB DATE 
NOTE 



PUB TYPE 

EDRS PRICE 
DESCRIPTORS 

IDENTIFIERS 



Smith, Carol L * ; Nealon, Bonnie M. 

Developing a CWIS — It's Not a Computing Center 
Pro j ect ♦ 

96 

lip.; In: Association of Small Computer Users in 
Education (ASCUE) Summer Conference Proceedings 
(29th, North Myrtle Beach, SC, June 9-13, 1996); see 
IR 018 247. 

Reports - Descriptive (141) — Speeches/Conference 
Papers (150) 

MF01/PC01 Plus Postage. 

^Computer System Design; Higher Education; 
Information Networks; Online Systems; Program 
Development; Strategic Planning; Total Quality 
Management; *World Wide Web 

*Campuswide Information Systems; *DePauw University 
IN 



ABSTRACT 

In December 1994, DePauw University (Greencas t 1 e , 
Indiana) began developing plans for creating its World Wide Web-based 
campus wide information system (CWIS) , DePauwINFO. Thirteen team 
members were recruited whose interests were intentionally diverse to 
ensure a broad representation of the entire campus community. A 
project timeline was proposed that involved two key milestones: 
developing a prototype CWIS to show at public open houses during 
Alumni Weekend; and continuing development over the summer, to finish 
the production by the beginning of the fall semester. To aid in 
defining the CWIS mission, five subcommittees were formed, each 
responsible for a major component of the development. When finished, 
the prototype CWIS contained more than 100 Web documents, and it 
illustrated a variety of Web capabilities ranging from simple 
text-based pages to ones with graphics, online forms, and searchable 
databases. Advertising bookmarks were developed and mailed to alumni 
and prospective students. Information sponsors were designated and 
contacted; sponsors then designated information providers, who were 
given basic training in the technology. The startup version of the 
CWIS went "live" during the second week of September. The final task 
was to define and ongoing governance team who would maintain the 
CWIS. A "direct ions” subcommittee was formed to recommend and 
prioritize issues that should be addressed. Guiding a team using 
total quality management methods proved to be a rewarding way to 
complete a project. (AEF) 
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Traditionally, developing and maintaining a campus wide information system (CWIS) has 
been the responsibility of a university's computing center. Indeed, the CWIS at many institutions 
began as a means for distributing very specific information relating to computing tools and services 
available to its more computer-savvy audience. The term “campus wide” often referred only to the 
fact that everyone on campus who had a computer account could access the CWIS. Then, the 
introduction of the World Wide Web (WWW) with its easy access to enormous amounts of 
information began to increase people's awareness of the possibilities of electronic information 
systems. Almost overnight, the audience of the traditional CWIS grew out of its campus boundaries 
to include off-campus visitors and became a worldwide audience including not only current students 
and staff, but alumni and prospective students, too. This newly expanded audience began to demand 
more than just information about computing resources available at their institution: They wanted to 
find up-to-date information about campus events, their classes and various other topics, and they also 
wanted to publish their own information. The CWIS essentially evolved from its simple campus- 
wide audience into a source of campus-wide information serving a world wide audience. It was no 
longer merely a way to distribute online computing help, but had become an important events 
calendar, educational resource, and marketing tool. The CWIS outgrew most computing centers' 
resources, so universities began restructuring their CWIS projects to include other members of the 
campus community for support. 

Initial Development: 
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With these thoughts in mind, in December 1994 DePauw University began to develop plans 
for creating its WWW-based campus wide information system, DePauwlNFO. Initial criteria for the 
CWIS deemed that it would focus on enhancing the academic environment at DePauw, while 
providing up-to-date postings about current events, services, and information about the University. 
The CWIS also should be available and easily accessible not only by all students, faculty and staff 
on campus, but also to alumni, prospective students and other visitors off campus. Thus, we gathered 
a team to begin the project. The team's two-part mission was to develop and set up the CWIS and 
to recommend a governance structure that would inherit the management of the system after initial 
start-up. We recruited thirteen team members whose interests were intentionally diverse to ensure 
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a broad representation of the entire campus community. Representatives on the team included a 
person from development/external affairs, student affairs, the registrar's office, the libraries, 
admissions, computing user support and system administration, and a faculty member and a student. 
This broad mixture of personalities and interests, we hoped, would lead to the necessary diversity 
in the design of the CWIS. 

We conducted team meetings and other processes in a TQM atmosphere in which we treated 
all participants equally and everyone was encouraged to participate freely. Early on, we created 
working guidelines to ensure that everyone understood and consented to the project mission. Using 
notions such as “it is ok to disagree,” “all ideas are respected,” and “all decisions are made by 
consensus” helped us to create an environment that proved invaluable to the success of the project. 
TQM methodology emphasized a common team goal and mission and cultivated an overall sense 
of team ownership of the project. Ultimately, it was this sense of project ownership that was the one 
of the most vital keys to the success of our CWIS. 

After formally defining and consenting to our team's mission, we proposed a project timeline 
that involved two key milestones: We would develop a prototype CWIS to show at public open 
houses during Alumni Weekend, June 1995. Then, using the experience learned from that 
development process and the audience' response as a basis, we would continue development over 
the summer and finish the production version by September 1995. Once the CWIS was in place, we 
would pass on the project to an ongoing governance team of our design. 

We knew that these dates were ambitious: We were expecting to finish our project in just a 
third of the time that we knew many other universities had spent. Nonetheless, we decided to invest 
a big part of our initial development time to develop policies, procedures and a clear mission of the 
CWIS before concentrating on physically creating it. Having a solid mission would serve as a 
foundation from which we could better define contents and decisions in the following months. 

To aid in defining the CWIS mission, we formed five subcommittees, each responsible for 
a major component of the development: “Purpose and content,” “users,” “presentation,” 
“hardware/software,” and “team management.” Each committee was to meet separately to research 
issues and then make recommendations to the whole team for consensus during full team meetings. 
We used this TQM method of doing work outside team meetings to reserve the meetings for focused 
decision making rather than arenas for pointless discussion. Making efficient use of our time was 
critical if we were going to finish the project on time. 

The subcommittees were defined as follows: The “purpose and content” committee was 
responsible for developing the initial policies of the CWIS. It dealt with issues of copyright, security 
and privacy of personal information, quality of contents, and standards. The “users” committee's 
initial purpose was to define the audience and what kinds of information would address its needs. 
It also addressed issues related to who would contribute information to the CWIS and how they 
would maintain accurate information. The “presentation” committee was to establish guidelines for 
page layouts on the CWIS. A CWIS is a publication of a university and it was imperative that every 
screen exhibited a quality presence of our institution. This subcommittee's goal was to design 
standard screen layouts that would simultaneously present a quality view of DePauw and a simple, 
consistent user interface. The “hardware/software” team had the responsibility of recommending and 
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installing the server hardware and software. This team also investigated appropriate development 
tools and began to experiment with creating documents. Finally, “team management” was the team 
leader, responsible for focusing the team on its mission and goals. This committee also served as 
liaison between the team and the rest of campus, periodically reporting our progress to the 
administration and coordinating CWIS publicity. 

After several months of developing policies and standards, we began to create the prototype. 
The purpose of the prototype was twofold: First, it would be a trial run for the procedures that we 
had so painstakingly put together. Second, since we were still working in a grassroots mode and were 
not yet officially recognized by upper administration, we hoped to use it to impress our test audience 
(primarily alumni, faculty and administrators) and gain their support for the CWIS. 

We brainstormed an extensive list of possible contents for the prototype CWIS. Then we 
assigned priorities according to categories of the items and whether they were readily available in 
electronic format. We were searching for information that would illustrate a diverse view of the 
overall campus and yet could be easily transformed into the appropriate hypertext format. Once we 
completed the list of contents, we contacted the appropriate owners of each piece of information and 
asked them to submit their items. We called these persons "information providers." Also, a new 
member whom we designated as the “html editor” was added to the development team. This person 
was to be responsible for coordinating other team members in acquiring the information, translating 
it into WWW format, and finally placing the documents on the CWIS. Our plan was that several 
team members would be involved in editing and testing the hypertext documents. 

Unfortunately, this plan did work out as well as we had hoped. Although various persons 
expressed an interest in learning how to create WWW documents and promised to assist with the 
prototype, only a couple of team members actually did the work. One reason for this was that most 
of us on the team had other work commitments that superseded the priority of the CWIS, especially 
those of us whose departments were directly involved with the upcoming alumni weekend events. 
However, the “team management” committee speculated that another factor also was involved in this 
situation. A few team members alluded that the computing center should be responsible for 
providing WWW document editing services for the University. Apparently, they agreed that 
individuals or departments should have control over selecting appropriate information for the CWIS, 
but should not be expected to deal with technical issues such as editing hypertext documents. Indeed, 
these ideas were not out of line from other similar database and report-generating services that the 
computing staff provided to some campus departments. Having non-computing staff perform this 
type of task was a new concept for some of our team members and it was an understandable reaction 
for them to stand back and let the others work on it. Realizing this, we noted that this was an 
important issue that we must resolve to complete the project. However, with our deadline rapidly 
approaching, we decided that we could resolve it later and directed our attention to finishing the 
prototype. In about three weeks' time, we gathered data from numerous information providers, 
converted it to hypertext format, and placed it on the server. When finished, our prototype CWIS 
contained more than one hundred WWW documents, and it illustrated a variety of WWW 
capabilities ranging from simple text-based pages to ones with graphics, online forms, and 
searchable databases. 

The completion of the prototype produced several positive results. First, after working on 
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policies for several months and finally having created a concrete product, the team was both elated 
and relieved — We had not only reached an important milestone in the project, but we had also met 
our first deadline. Second, the audience's reaction was overwhelmingly enthusiastic. Alumni were 
especially positive about having easy access to university information, and many also commented 
on the educational possibilities that the CWIS would provide. Finally, the university administrators 
who viewed the prototype also were receptive to its possibilities and pledged their willingness to 
support the continuance of the project, both administratively and financially. Overall, it was a 
significant step toward the success of the project. 

On the other hand, the prototype development also exposed an interesting challenge to the 
team. We realized that the method used to create and update documents on the prototype was not 
going to work well for long term maintenance of the CWIS. It was evident that one or two persons 
alone simply could not maintain the contents of a full-blown CWIS. As a solution, we proposed and 
agreed to take the “information provider” idea a step further by encouraging persons not only to 
submit their information but to create and maintain their own documents, too. Each piece of 
information on the CWIS would have a "sponsor" who actually owned the contents and would have 
the responsibility for document preparation and maintenance. Each sponsor, then, would designate 
an information provider (IP) who would do the necessary preparation and editing of documents. We 
proposed that the “html editor” role would be transformed into that of an “IP coordinator.” That 
person would be responsible for assisting information providers in maintaining their documents, 
coordinating WWW and html training, coordinating the installation of editing tools at their desktops, 
and providing other assistance as needed. The IP coordinator's goal would be to enable the 
information providers to edit their own documents, but not to do the editing for them. 

Coming to a consensus on this decision was not an easy task for the team. Although everyone 
agreed that our original plan needed adjustments, not everyone was convinced that persons in other 
departments could maintain their own files. Some found it difficult to ignore the old paradigm of 
persons being dependent on the computing center. Nonetheless, of the solutions we presented, this 
method appeared to be the most viable and the team consented to try it. As a compromise, we agreed 
to first test the procedures internally by using team members as the first new information sponsors 
before we collected other persons from campus. That way, we could work out the flaws in the plan 
using participants who would be more willing to experiment with different approaches than others 
outside our team might be. Since the campus was represented so completely by the development 
team members, we could still present an initial set of contents that exhibited a full view of the 
university. Using this technique, we planned to develop a solid set of procedures for information 
sponsors that the governance team could then evaluate and determine whether to adopt or redesign. 

Thus, we began the last stretch of development, anticipating several major components: We 
needed to develop the appropriate training and development tools to enable information providers 
to begin developing their WWW documents. We had to complete key policy issues relating to 
governance of the CWIS. We needed to determine appropriate members and gather together the 
ongoing governance team that would inherit the project. Finally, we needed to begin educating our 
audience about the forthcoming CWIS. 

We developed advertising bookmarks that were mailed to alumni and prospective students 
in early August. Notifying the alumni, perhaps our largest category of audience, about the coming 
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CWIS proved to be the catalyst that marked the reality of the project completion. Throughout the 
project, our goal date had always been September, but officially committing ourselves to that date 
finalized the deadline. Bringing the team to a consensus on the decision to advertise a startup date 
for the CWIS before it was finished was difficult. A few members of the team were skeptical about 
the proposed completion date and were concerned that the University would suffer embarrassment 
if we did not meet the deadline. Most of the team members, however, were confident about meeting 
our deadline and convinced those others to follow along. The doubters may have not agreed with our 
decision to advertise so early, but they consented that it was a necessary choice for the team to make. 

For the last time, we evaluated the list of contents and selected items for the production 
startup. By late July, we had formally designated and contacted information sponsors based on that 
list. As was our plan, most of the sponsors were development team members. Still, we found that 
we also had to add a few non-team persons to the list to ensure that we had a cross-campus set of 
initial contents, so we held a startup workshop for all of the sponsors to explain formally their 
responsibilities. Sponsors were advised to meet with other members of their departments to explain 
the mission of the CWIS. The departments were to consider our list of initial contents for their 
department and update it to include items that they thought were most important. Then, each sponsor 
was directed to designate an IP and explain that role in the project. Once the IPs were designated, 
they were to be given release time to experiment with browsing the WWW to gather a better 
understanding of their role. 

Training that first set of information providers proved to be an interesting challenge. By the 
time we finally began to work with them, the advertisements had been distributed and the September 
deadline was looming near. Also, since most of them had limited experience in using the Internet 
for anything other than exchanging E-Mail, we were not sure how quickly they would grasp the 
concepts of the World Wide Web and its capabilities. Nor were we sure about what kind of training 
would most effectively teach them. With the assumptions that sponsors had already outlined the 
goals of the CWIS and that IPs had spent time browsing the WWW, we began by presenting a two- 
hour workshop that focussed on the basics of creating html documents. The workshop briefly 
described the WWW and illustrated Lynx, the text-based browser that we were using. Its emphasis, 
however, was on explaining a Windows-based html editor and tools for creating and testing 
hypertext documents. At the end of the workshop, participants were directed to a computing 
laboratory where they could experiment with the tools covered in the presentation. Afterwards, we 
told them that we would install the appropriate tools on their own desktops as soon as possible. 
Meanwhile, they could return to the laboratory anytime to work on their documents. We encouraged 
persons to work in groups, stressing the advantages of exchanging ideas and solutions with other 
persons. 

Soon after this first workshop, we realized that we had overestimated the basic knowledge 
of some information providers. We had not anticipated that some of them were unfamiliar with using 
Microsoft Windows. Thus, before we offered the next hypertext workshop, we provided an optional 
Windows workshop for those persons. Also, some Macintosh users had difficulty translating the 
demonstrated Windows-based commands to the Macintosh environment, so we provided an 
additional workshop that illustrated Macintosh-based tools. Finally, not all of the sponsors had 
described completely the role of the information provider to their IPs before sending them for 
training. In an extreme case, one information provider showed up for the workshop with literally no 
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idea why she had been sent. Given the limited time that we had to work in, we chose to resolve this 
issue on an individual basis rather than adding specific training time to deal with it. We did note, 
though, that we could not always rely on sponsors to relay basic DePauwINFO information to their 
IPs and that we should build this type of information into the next series of IP training. With these 
issues resolved, finally, we followed up with another html workshop that dealt with more advanced 
hypertext techniques. 

Meanwhile, our goal was to install an html editor and graphical browser at every information 
provider's desktop, but one main obstacle presented itself. DePauw still has several x286-based 
DOS -compatible computers that are incapable of running Windows-based programs. Unfortunately, 
all of the WWW tools that we were using required Windows to run. With this round of IPs, 
compromises were made and we were able to find appropriate solutions for everyone. However, we 
knew that this problem would appear again as new IPs were designated and that we would need to 
find ways to resolve it in the future. 

While we were training the information providers, a subcommittee was working to finalize 
policies and procedures. From our experiences throughout the project, we realized that we could only 
speculate about what types of policies would be most important in the months following startup. We 
agreed that the formal policies we developed should serve only as an initial set of guidelines for the 
ongoing governance team. That committee should periodically review the CWIS policies and 
procedures and amend them as necessary to suit the needs of the project. The key recommendations 
that we passed on to the governance team were as follows: We proposed a moratorium against 
adding new information sponsors for several months. The existing set of IPs would be free to add 
and update their documents, but new sponsors would not be initiated until the committee had time 
to develop stable training procedures and resolve critical equipment issues. We suggested that 
personal student homepages would not be allowed on the CWIS until the University had investigated 
the legal issues involved with them. And, once the team was prepared for the next IPs, we 
recommended that it especially target academic departments and student life representatives, as those 
were areas most lacking contents on the CWIS. The governance team could choose to accept or 
readdress these recommendations as they saw fit, but these were the most important concerns that 
we noted at the time. 

Finally, we completed the startup version of our CWIS and it went “live” during the second 
week of September. Thanks to the gritty efforts of the newly-trained information providers, we not 
only finished on time, but we beat the deadline by nearly two weeks. As was our goal, the CWIS 
contained information from all parts of campus and none of the documents had been edited by the 
computing center. Those areas that we were unable to fill, primarily because the appropriate persons 
had been unavailable during the summer months, were alluded to by place marks in the pages — 
nonactive hyperlinks to information that would be added in the future. Those of us on the 
development team firmly believed that we had fulfilled our mission by creating a truly “campus 
wide” information system. 

Ongoing Development and Maintenance: 

Before disbanding, our final task was to define and gather an ongoing governance team who 
would take over the CWIS. This committee would be responsible for maintaining the project by 
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developing and enforcing policies and procedures, ensuring that the CWIS was meeting its original 
mission and vision, and encouraging its future growth. We presented and gained approval from the 
university president for our recommendations of the team membership and reporting structure. We 
proposed that this team would report to the provost and, like the development team, would consist 
of a diverse group representing all facets of the University. Membership included fourteen persons 
selected as follows: four appointments by the provost, including a representative from the registrar's 
office and one from the University libraries, three faculty members chosen by the faculty, one 
appointment by the vice president for development and alumni affairs, the director of academic 
computing, the information provider coordinator, the CWIS systems administrator, a representative 
from the office of admissions, and two students appointed by student government. 

We held the first meeting of the governance team approximately two months after the CWIS 
had been established. We quickly learned that the new team members showed diversity in more than 
just their appointment areas: Although many of the members had been part of the original 
development team and were aware of the struggles and conflicts of developing a CWIS, the others 
needed to learn about the mission of the CWIS, what their responsibilities would be and how the 
team would function to meet its goals. At the first meeting, we spent time discussing the project and 
what our role in its mission would be. Similar to the development team, we agreed to hold meetings 
in a TQM atmosphere to build team unity, and we established guidelines to set the style for meetings. 
We also selected a team member to serve as the facilitator. At the end of the first meeting, a 
"directions" subcommittee was formed to recommend and prioritize issues that should be addressed 
by the governance team. Also, we formed a subcommittee composed of faculty members to develop 
guidelines for academic department homepages. 

The "directions" group then met and identified the following key issues for maintaining and 
governing the CWIS: Obtaining hardware and software, ensuring accuracy and legality of 
information, revising policies and procedures to reflect evolution, adding and training information 
providers, investigating student participation, advertising, and assessing the CWIS. These 
recommendations were presented to the full team and other concerns were added to the list. We 
ranked the tasks and created four subcommittees: “hardware and software,” “accuracy and legality,” 
“outreach,” and “student publications.” Meanwhile, a subcommittee from the original group of IPs 
was creating a handbook that would assist in training new information providers. We also discussed 
public relations issues such as how to encourage the University community to rely on the CWIS for 
current campus information and we noted the need for assessment to evaluate the effectiveness of 
the CWIS. 

We considered hardware and software to be high priority issues. Currently we were 
maintaining the server and all of the CWIS documents on the academic mainframe. This computer 
contained personal accounts for all students, faculty and selected staff, and we were concerned about 
performance degradation caused by heavy traffic to our CWIS. Therefore, we needed to purchase 
a dedicated computer for the Web site. Also, we were concerned about what type of hardware and 
software would be needed by our information providers to create their own hypertext documents for 
the CWIS. Additionally, we proposed that the governance team might advise the University about 
the types of hardware and software needed to support the CWIS in a networked campus. The 
“hardware and software” committee was assigned the responsibility of resolving these issues. The 
“accuracy and legality” subcommittee was directed to address issues of accuracy, legality and 
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avoidance of redundancy on the CWIS. It was proposed that we might establish one office or group 
to monitor for inaccuracies, and that we should encourage information providers to link to other 
information pages rather than duplicating them. The “outreach” committee was to address and 
resolve outreach issues such as soliciting new information providers, encouraging sponsors to keep 
their information current and accurate, aiding sponsors in identifying information from their area, 
instructing sponsors and IPs on copyright limitations, liability and slander, and training IPs to create 
hypertext documents. Finally, “student publications” was to resolve student involvement issues 
including the addition of student homepages, liability issues relating to those pages and 
encouragement for student groups to participate on the CWIS. Each subcommittee developed its own 
mission statement to keep it focused on its tasks. They have defined and prioritized the tasks 
necessary to complete their missions and assigned deadlines to each task. 

Currently, the governance committee is involved with short term projects: the purchase of 
server hardware, the outreach for new information providers, and the issue of student involvement. 
However, we plan to resolve these issues quickly so that we can focus more on long range goals for 
the CWIS. The team should be more concerned with overall development of policies and procedures 
of the project and less involved with the day-to-day operations. Our team goal for the future is to 
anticipate potential stumbling blocks so that we can handle them in a proactive rather than a reactive 
manner. We also foresee that positions initially created to implement the production CWIS, such as 
the IP Coordinator, will evolve with new responsibilities to better meet the needs of the project. With 
the formation of an outreach subcommittee and the existence of new html software which make the 
creation of Web documents much easier, we may even find less need for formal training. Meanwhile, 
our most immediate goal for the CWIS is to establish it on campus as the definitive source of 
information about the University. 

What We Learned: 

Guiding a team using TQM methods can be a very rewarding way to complete a project. By 
building a sense of team unity that focuses all participants on a common goal, TQM often directs 
even the most diverse team members toward the successful completion of a project. Also, in our 
experience, the technique of employing a group of individuals with varying backgrounds to 
accomplish tasks results in more well rounded and better-prepared products. Nonetheless, TQM can 
pose challenges to teams made up of persons unaccustomed to working under its guidelines. For one, 
coming to a team consensus on every decision is often time-consuming and is not always a simple 
process. Persons who are more used to working in a democratic environment in which they decide 
quickly by voting are sometimes frustrated by the discussions and compromises needed to bring a 
team to a consensus. We also experienced a challenge in working with persons new to TQM that 
resulted from the makeup of the team itself. Our development team consisted of a wide range of 
individuals, many of whom were department directors. Those persons were not used to surrendering 
the “control” of handling tasks and working in an environment in which everyone was considered 
equal. They sometimes were uncomfortable with trusting others to accomplish tasks without their 
direct supervision. Hoping to avoid friction caused by these frustrations, our team leaders devoted 
a great deal of energy at the project startup to build TQM skills and guidelines for the team to follow. 
As the project progressed they had to be keenly aware of each team member's acceptance level and 
be prepared to resolve situations in which some found it difficult to adapt. At first, we were uncertain 
about whether these activities were necessary and were concerned that we had wasted valuable 
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project time. However, in retrospect, we firmly believe that the overall sense of project ownership 
and the resulting commitment of the team members, cultivated by TQM methodology, was the key 
factor that attributed the most to our CWIS' success. 

Although we expected to encounter a few obstacles in providing necessary development tools 
to the information providers, we were startled by the shortage of appropriate equipment available 
to support those tools on our campus. We easily found Macintosh-based editing tools that would run 
on almost every Macintosh computer on our campus. However, we have many low-end DOS- 
compatible computers that are incapable of running the Windows-based editing software that we 
originally selected. This forced us to look into alternative, perhaps not so user-friendly, solutions for 
creating and testing hypertext documents on DOS computers. Unfortunately, we have found that the 
most sophisticated hypertext editors and browsers are available only for the Windows platform and 
that similar tools for the DOS-only platform are less user-friendly and provide fewer user options. 
For us, this presents a Catch-22 situation: The people who have a low-end DOS computers are likely 
to the ones who have had less opportunity to experiment with different computing tools and 
subsequently have less overall computing knowledge. Ironically, these persons are the ones who 
could benefit the most from having the sophisticated tools for maintaining their CWIS documents, 
yet they are the most difficult to sufficiently equip. We are currently investigating alternative 
solutions for those information providers, such as providing hypertext tools in the public computing 
laboratories or recommending to the administration that IPs should be high on the list of persons who 
receive updated equipment. So far, though, we have not completely resolved this situation at our 
university, largely because decisions made about equipment purchase often depend more on the 
university budget than on user needs. 

Initially, to ensure that the topics presented would represent a broad range of campus 
information, we identified a contents list and highlighted items as key content documents for our 
startup CWIS. Still, when we introduced our CWIS, we found some obvious omissions of 
information about certain areas of the university, namely, student affairs, the school of music and 
student life. Additionally, after we had identified contents and began to determine the appropriate 
owner for each piece, we discovered that it was not always clear who owned the information. For 
example, we were told that one department was recognized as the official source of the University 
calendar, yet we found two other areas who also kept events calendars that they believed were more 
complete. In hindsight, we realize that we may have concentrated too much on identifying specific 
information for the CWIS. Instead, we might have gained more positive results by identifying 
university departments that should be represented and encouraging them to identify the specific 
contents themselves. 

Looking to the future, at some point we will need to address the issue of measurement: Are 
we still focused on our original mission? What are our customer service goals and how will we know 
that we have achieved them? We may want to create an online visitors' survey to check if our off- 
campus users are finding useful information. We will also need to survey our students, faculty and 
staff to find out if they use the CWIS to find useful campus information and ask them what type of 
information they want to see on our Web site. We will need to track things such as the number of 
admissions inquiries that are received via the CWIS or how many “hits” we receive on our welcome 
page and other key homepages. The only way to ensure that we have created a successful product 
that is useful to our audience is to continually ask, “How can we improve?” 



O 144 

ERIC 



10 



1996 ASCUJE Proceedings ? 

Finally, through the experience of this project, we are firmly convinced that developing and 
maintaining a CWIS is not a computing center project. Certainly, the computing center plays a 
critical role by supporting the technology of the CWIS, maintaining the server hardware and 
software, investigating updated client programs and development tools, and providing support and 
training for the information providers. However, without intending to downplay the importance of 
that support, technical support is merely a small portion of the diverse range of services necessary 
to maintain the system. A good CWIS requires that all areas of campus are equally represented and 
supported by its contents and services. Ensuring that goal requires that a diverse group of individuals 
from all parts of the institution be responsible for the key decision making that drives the CWIS. 
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